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Abstract 

Formal  specifications  of  required  system  behavior  can 
be  analyzed,  verified,  and  validated,  giving  high  confidence 
that  the  specification  captures  the  desired  behavior.  Trans¬ 
ferring  this  confidence  to  the  system  implementation  de¬ 
pends  on  a  formal  link  between  requirements  and  imple¬ 
mentation.  The  automatic  generation  of  provably  correct 
code  provides  just  such  a  link.  While  optimization  is  usu¬ 
ally  performed  on  code  to  achieve  efficiency,  we  propose 
to  optimize  the  formal  specification  before  generating  code, 
thus  providing  optimization  independent  of  the  particular 
code  generation  method.  This  paper  investigates  the  use  of 
invariants  in  optimizing  code  generated  from  formal  speci¬ 
fications  in  the  Software  Cost  Reduction  (SCR)  tabular  no¬ 
tation.  We  show  that  invariants  (1)  provide  the  basis  for 
simplifying  expressions  that  otherwise  cannot  be  improved 
using  traditional  compiler  optimization  techniques,  and  (2) 
allow  detection  and  elimination  of  parts  of  the  specification 
that  would  lead  to  unreachable  code. 


1.  Introduction 

Formal  requirements  specifications  are  useful  because 
they  can  be  analyzed  to  show  that  they  satisfy  critical  prop¬ 
erties  such  as  safety,  security,  and  timeliness.  Additionally, 
with  executable  specifications,  the  user  may  symbolically 
execute  the  system  to  validate  that  the  specification  captures 
the  intended  system  behavior.  Thus,  analysis  and  simulation 
can  provide  confidence  that  a  specification  is  correct.  Trans¬ 
ferring  this  confidence  to  the  implementation  requires  a  for¬ 
mal  link  between  requirements  and  implementation.  This 
formal  link  may  be  realized  by  a  sequence  of  (usually)  man¬ 
ual  refinements,  but  the  automatic  generation  of  provably 
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correct  code  provides  the  highest  confidence  that  the  code 
captures  the  specified  behavior.  We  have  shown  in  previous 
work  [21]  how  to  construct  code  from  requirements  speci¬ 
fied  in  the  Software  Cost  Reduction  (SCR)  tabular  notation. 
The  development  of  high-quality  SCR  requirements  speci¬ 
fications  is  supported  by  a  suite  of  editing  and  verification 
tools  designed  and  developed  by  the  Naval  Research  Labo¬ 
ratory.  Automatic  code  synthesis  is  consistent  with  our  SCR 
toolset  design  philosophy,  the  goal  of  which  is  to  automate 
(as  much  as  possible)  the  process  of  system  specification, 
analysis,  and  implementation  using  tools  and  methods  de¬ 
signed  for  practicing  engineers. 

Both  speed  and  code  size  are  important  in  code  for  em¬ 
bedded  systems.  Compilers  generally  perform  optimiza¬ 
tions  for  speed,  while  code  size  optimization  is  often  done 
by  hand  on  either  the  source  code  or  the  compiled  code  [28]. 
Rather  than  perform  optimizations  only  on  the  code  itself, 
our  approach  is  to  translate  the  formal  specification  into  an 
equivalent  form  that  will  lead  to  smaller,  and  frequently 
faster,  code  than  the  original  specification,  thus  providing 
optimization  independent  of  the  particular  code  generation 
method.  This  will  then  be  followed  by  more  typical  opti¬ 
mizations  on  the  code.  This  paper  investigates  the  use  of 
requirements  level  invariants  in  optimizing  code  generated 
from  executable  formal  requirements  specifications  repre¬ 
sented  in  the  SCR  tabular  notation.  Invariants  are  proper¬ 
ties  that  hold  in  every  reachable  state  of  such  an  executable 
system.  In  previous  work,  we  have  developed  algorithms 
for  automatically  generating  invariants  [16,  17];  these  and 
other  invariants  that  have  been  established  can  be  used  with 
our  techniques. 

To  illustrate  our  notion  of  optimization,  we  consider  a 
simple  state  machine  E  with  state  set  {xi,  2:2}.  Associated 
with  E  is  a  variable  X,  whose  value  represents  the  current 
state  of  E,  and  Boolean  variables  A  and  B.  The  machine 
E  changes  state  based  on  (and  in  parallel  with)  changes  in 
A  and  B.  Here  and  below,  we  follow  the  standard  conven¬ 
tion  in  which  unprimed  variables  represent  values  prior  to  a 
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transition  and  primed  variables  represent  values  after  a  tran¬ 
sition. 


A  A  -'A' 


B  A  ->B'  A  A 


Figure  1.  Simple  Example  State  Machine 

Figure  1  indicates  that,  whenever  S  enters  state  x\,  A 
holds.  This  is  because  (1)  in  S’s  initial  state  x\,  A  holds, 
and  (2)  A  holds  after  the  machine  enters  state  X\  from  state 
X2\  this  follows  from  the  label  -*A  A  A '  on  the  (unique) 
transition  from  state  a:2  to  state  X\  and  the  convention  on 
primes.  Also  from  Figure  1,  if  while  £  is  in  state  x\,  A 
changes  from  true  to  false  (i.e.,  A  A  -<A'),  then  the  ma¬ 
chine  exits  state  x\.  (We  assume  a  semantics  that  forces 
a  transition  whenever  one  is  possible,  even  if  the  choice  is 
nondeterministic.)  Given  this,  it  is  easy  to  show  that  A  al¬ 
ways  holds  when  the  machine  is  in  state  Xi,  or,  in  other 
words,  the  expression  ( X  =  x± )  =>  A  is  invariant.  In  fact, 
a  generalization  of  this  observation  is  the  basis  for  our  algo¬ 
rithms  for  invariant  generation  [16,  17], 

Notice  that,  in  state  xi,  if  B  changes  from  true  to  false , 
and  A  holds  before  this  change  (i.e.,  B  A  -> B'  A  A  holds), 
then  the  machine  enters  state  X2-  However,  it  is  redundant 
to  check  that  A  holds  as  part  of  the  evaluation  B  A  —>B’  A  A 
since  A  always  holds  in  state  x\  due  to  the  invariant  prop¬ 
erty  given  above.  Thus,  we  may  simplify  the  expression 
labeling  this  tr  ansition  to  B  A  ->B'  to  avoid  checking  A. 

The  transitions  illustrated  by  Figure  1  may  be  expressed 
in  a  tabular  format  as  follows: 


source  state 

guard 

target  state 

Xi 

A  A  ->A' 

X2 

Xl 

B  A  iB'  A  A 

X2 

X2 

-■A  A  A! 

X\ 

The  SCR  method  uses  similar  tables  to  define  state  machine 
transitions.  The  above  table  is  a  compact  representation  of 
the  function  defining  X1,  the  value  of  variable  X  in  the  new 
state.  The  standard  mathematical  definition  of  the  function 
is  more  complex: 

!x2  if  X  =  Xi  A  ({A  A  -i A')  V  (i?  A  ->B'  A  A)) 
X\  if  X  =  X2  A  (->A  A  A') 

X  otherwise 

The  simplification  performed  above  can  be  used  to  in¬ 
duce  a  transformation  of  the  table.  The  cells  comprising 


the  guard  column  of  the  table  are  the  focus  of  our  sim¬ 
plifications.  We  are  able  to  perform  the  simplification  be¬ 
cause  (1)  the  system  is  in  state  x\  (i.e.,  X  =  Xi),  (2)  the 
invariant  (X  =  x\)  =>  A  always  holds,  and  (3)  the  pre¬ 
vious  two  facts  together  imply  that  A  holds.  If  we  take 
K  =  ( X  =  X\)  A  (. X  =  X\  =>  A)  to  be  the  context  of 
the  cell  containing  the  expression  B  A  ~^B'  A  A,  then  our 
simplification  may  be  expressed  as  follows. 

If  K  is  the  context  for  a  cell  containing  the  expres¬ 
sion  E  and  K  =>  A  then,  A  may  be  replaced  by 

true  in  E. 

A  generalization  of  the  above  rule  to  replace  any  subex¬ 
pression  (rather  than  just  the  Boolean  variable  A)  is  one  of 
the  simplification  rules  that  we  have  developed.  However, 
the  simplification  is  not  yet  complete  because  this  rule  says 
that  B  A  ~>B'  A  A  is  transformed  into  B  A  -i B’  A  true. 
Transforming  this  expression  to  B  A  —  PA  is  trivial;  we  sim¬ 
plify  using  the  identity  P  A  true  P.  In  the  general  case, 
we  apply  this  and  other  standard  Boolean  simplifications. 
Transforming  the  table  as  described  results  in  a  table  with  a 
simplified  middle  row: 


source  state 

guard 

target  state 

X\ 

-iA' 

X2 

Xi 

B  A  -<B' 

X2 

X2 

-■A  A  A! 

Xl 

Note  that  the  simplification  rule  with  the  same  context  has 
also  been  applied  to  remove  the  term  A  from  the  guard  cell 
of  the  first  line  of  the  table. 

This  simple  example  illustrates  that  invariants  can  pro¬ 
vide  the  basis  for  simplifying  expressions  that  cannot  be  fur¬ 
ther  simplified  without  use  of  those  invariants.  Such  modi¬ 
fications  are  a  form  of  contextual  simplification ,  analogous 
to  contextual  rewriting  [35],  since  they  involve  the  use  of  a 
context  of  known  facts  to  aid  in  the  simplification.  In  addi¬ 
tion  to  the  generalization  of  the  above  rule,  we  also  develop 
rules  for  detecting  and  eliminating  parts  of  the  specifica¬ 
tion  that  would  lead  to  unreachable  code.  Our  general  ap¬ 
proach  is  to  apply  a  convergent  set  of  contextual  simplifica¬ 
tion  rules,  each  application  of  which  may  require  additional 
non-contextual  simplification. 

While  this  paper  considers  only  a  set  of  simple  rules  for 
simplifying  propositional  formulas,  we  are  in  the  process  of 
investigating  more  sophisticated  techniques  to  include  ac¬ 
tual  algorithms  for  doing  these  optimizations,  as  well  as  ex¬ 
tension  to  contextual  simplification  of  a  more  general  nature 
(e.g.,  simplification  of  arithmetic  expressions). 

Section  2  provides  background  on  SCR  and  on  invari¬ 
ants  that  can  be  automatically  derived  from  SCR  specifi¬ 
cations.  Section  3  explains  how  invariants  may  be  used  to 


simplify  SCR  tables  by  removing  portions  of  the  specifica¬ 
tion  that  would  lead  to  unnecessary  or  dead  code.  Examples 
are  given  to  illustrate  the  utility  of  invariants  in  this  process. 
Section  4  discusses  related  work.  Section  5  presents  con¬ 
clusions  and  ideas  for  future  work. 

2.  Background 

Originally  formulated  to  document  the  requirements  of 
the  flight  program  of  the  U.S.  Navy’s  A-7  aircraft  [14],  the 
SCR  requirements  method  is  designed  to  support  detection 
and  correction  of  errors  during  the  requirements  phase  of 
software  development  [13,  9].  The  SCR  toolset  provides 
a  user-friendly  approach  to  writing  requirements  specifica¬ 
tions  in  a  tabular  format  and  a  number  of  analysis  tools, 
including  a  consistency  checker  [13],  a  simulator  [12],  a 
model  checker  [10],  theorem  provers  [2, 4],  and  an  invariant 
generator  [16,  17].  By  applying  the  SCR  tools  to  uncover 
errors,  a  user  can  develop  high  confidence  that  a  specifica¬ 
tion  correctly  captures  the  required  system  behavior. 

The  SCR  method  has  been  used  successfully  by  many 
organizations  in  industry  and  in  government  (e.g..  Bell  Lab¬ 
oratories  [15],  Grumman  [26],  Lockheed  [7],  the  Naval 
Research  Laboratory  [10,  20],  Ontario  Hydro  [31],  and 
Rockwell  Aviation  [27])  to  develop  and  analyze  specifi¬ 
cations  of  practical  systems,  including  flight  control  sys¬ 
tems  [7,  27],  weapons  systems  [10],  space  systems  [6],  and 
cryptographic  devices  [20],  Most  recently,  the  SCR  tools 
were  used,  together  with  a  test  case  generator,  by  Lockheed 
Martin  to  detect  a  critical  error  described  as  the  “most  likely 
cause”  of  a  $165  million  failure  in  the  software  controlling 
landing  procedures  in  the  Mars  Polar  Lander  [5], 

2.1  SCR  Requirements  Model 

In  SCR  the  required  system  behavior  is  defined  in  terms 
of  monitored  and  controlled  variables,  which  represent 
quantities  in  the  system  environment  that  the  system  mon¬ 
itors  and  controls.  The  environment  nondeterministically 
produces  a  sequence  of  monitored  events,  where  a  moni¬ 
tored  event  signals  a  change  in  the  value  of  some  monitored 
variable.  The  system,  represented  in  the  model  as  a  state 
machine,  begins  execution  in  some  initial  state  and  then  re¬ 
sponds  to  each  monitored  event  in  turn  by  changing  state. 
In  SCR  the  system  behavior  is  assumed  to  be  synchronous : 
the  system  completely  processes  one  set  of  inputs  before 
processing  the  next  set.  Furthermore,  the  One  Input  As¬ 
sumption  allows  at  most  one  monitored  variable  to  change 
from  one  state  to  the  next. 

To  specify  the  required  behavior  concisely,  the  SCR 
model  contains  two  types  of  auxiliary  variables:  mode 
classes,  whose  values  are  called  modes,  and  terms.  Each 


mode  is  an  equivalence  class  of  system  states  useful  in  spec¬ 
ifying  as  well  as  understanding  the  required  system  behav¬ 
ior.  A  term  is  a  state  variable  defined  by  an  expression  over 
monitored  variables,  mode  classes,  or  other  terms.  Mode 
classes  and  terms  often  capture  history — the  changes  that 
occurred  in  the  values  of  the  monitored  variables — and  help 
to  make  the  specification  more  concise. 

The  SCR  model  represents  a  system  as  a  state  machine 
E  =  ( S ,  S0,  Em,T),  where  S  is  the  set  of  states.  So  C  S 
is  the  set  of  initial  states,  Em  is  the  set  of  monitored  events, 
and  T  is  the  transform  describing  the  allowed  state  transi¬ 
tions  [13].  In  our  model,  the  transform  T  is  a  function  that 
maps  a  monitored  event  e  €  Em  and  the  current  state  s  £  S 
to  the  next  state  s'  £  S.  Further,  a  state  is  a  function  that 
maps  each  state  variable,  i.e.,  each  monitored  or  controlled 
variable,  mode  class,  or  term,  to  a  type-correct  value;  a  con¬ 
dition  is  a  predicate  defined  on  a  system  state,  and  an  event 
is  a  predicate  requiring  that  two  consecutive  system  states 
differ  in  the  value  of  at  least  one  state  variable. 

The  notation  “@T  ( c)  WHEN  d”  denotes  a  conditioned 
event,  which  is  defined  by 

@T(c)  WHEN  d  =f  -ic  A  c7  A  d, 

where  the  unprimed  conditions  c  and  d  are  evaluated  in  the 
current  state  and  the  primed  condition  d  is  evaluated  in  the 
next  state.  The  event  @T  (c)  WHEN  d  occurs  when  its 
defining  expression  evaluates  to  true.  We  also  define 

@F  (c)  =  @T(-ic). 

2.2  The  SCR  Tables 

The  transform  T  is  a  composition  of  smaller  functions 
called  table  functions,  which  are  derived  from  the  condi¬ 
tion  tables,  event  tables,  and  mode  transition  tables  in  SCR 
requirements  specifications.  These  tables  define  the  values 
of  the  dependent  variables — the  controlled  variables,  mode 
classes,  and  terms.  For  T  to  be  well-defined,  no  circular  de¬ 
pendencies  are  allowed  in  the  definitions  of  the  dependent 
variables.  The  variables  are  partially  ordered  based  on  the 
dependencies  among  the  next  state  values. 

Each  table  defining  a  term  or  controlled  variable  is  ei¬ 
ther  a  condition  table  or  an  event  table.  A  condition  ta¬ 
ble  associates  a  mode  and  a  condition  in  the  next  state  with 
a  variable  value  in  the  next  state,  whereas  an  event  table 
associates  a  mode  and  a  conditioned  event  with  a  variable 
value  in  the  next  state.  Each  table  defining  a  mode  class 
is  a  mode  transition  table,  which  associates  a  source  mode 
and  an  event  with  a  target  mode.  Our  formal  model  requires 
the  information  in  each  table  to  satisfy  certain  properties, 
guaranteeing  that  each  table  describes  a  total  function  [13]. 
Some  SCR  tables  may  be  modeless,  i.e.,  they  define  the 
value  of  a  variable  without  referring  to  any  mode  class. 


Old  Mode 

Event 

New  Mode 

TooLow 

@T(WaterPres  >  Low) 

Permitted 

Permitted 

@T(WaterPres  >  Permit) 

High 

Permitted 

@T(WaterPres  <  Low) 

TooLow 

High 

@T(WaterPres  <  Permit) 

Permitted 

Table  1.  Mode  Transition  Table  for  Pressure. 


Mode 

Conditions 

High,  Permitted 

True 

False 

TooLow 

Overridden 

NOT  Overridden 

Safety-Injection 

Off 

On 

Table  2.  Condition  Table  for  Safety.in  jection. 


To  illustrate  the  SCR  tabular  notation,  three  example  ta¬ 
bles  are  presented.  These  tables  define  the  values  of  the 
three  dependent  variables  in  a  simplified  version  of  a  safety 
injection  system  (SIS)  [13]  for  a  nuclear  power  plant.  The 
SIS  system  monitors  water  pressure,  and  if  the  pressure  is 
too  low,  the  system  injects  coolant  into  the  reactor  core. 

Table  1  is  a  mode  transition  table  defining  the  new  value 
of  the  mode  class  Pressure  as  a  function  of  the  current 
mode  and  the  monitored  variables.  For  example,  the  first 
row  of  the  table  states  that  if  the  current  mode  is  TooLow 
and  the  water  pressure  becomes  greater  than  or  equal  to  the 
Low  threshold,  the  new  mode  is  Permitted. 

Table  2  is  a  condition  table  defining  the  value  of 
the  controlled  variable  Safety_Injection  as  a  function 
of  the  modes  and  the  term  variable  Overridden.  The 
first  row  states  that  in  the  High  or  Permitted  modes, 
Safety_Injection  is  Off.  The  second  row  states 
that  in  the  mode  TooLow,  if  Overridden  is  true  then 
Safety_Injection  is  Off,  and  if  Overridden  is  false 
then  Safety_Injection  is  On. 

Table  3  is  an  event  table  defining  the  term  Overridden 
as  a  function  of  the  current  mode  and  the  monitored  vari¬ 
ables.  The  first  row  describes  the  behavior  when  the  mode 
of  the  system  (i.e.,  the  value  of  Pressure  in  the  old  state) 
is  either  TooLow  or  Permitted.  In  either  of  these  modes,  if 
Block  switches  to  On  when  Reset  is  Off,  then  the  new 
value  of  Overridden  is  true,  but  if  the  Pressure  be¬ 
comes  High  or  Reset  switches  to  On,  then  the  new  value 
of  Overridden  is  false. 

2.3  Invariants  and  Code  Generation 

We  consider  two  forms  of  invariants  in  SCR:  state  in¬ 
variants,  expressions  over  a  single  state  that  hold  in  each 
reachable  state  of  the  system,  and  transition  invariants,  ex¬ 
pressions  over  two  states  that  hold  for  each  reachable  pair 


of  consecutive  states.  We  have  designed  two  algorithms 
[16,  17]  for  constructing  state  invariants  from  the  tables 
defining  the  dependent  variables  in  an  SCR  specification. 
Suppose  that  dependent  variable  r  has  values  in  a  finite  set 
{ Vi ,  i>2 ,  ■  ■  ■ ,  vn  }.  If  the  value  of  r  is  defined  by  a  mode  transi¬ 
tion  table  or  an  event  table,  then,  for  each  v.t,  the  algorithms 
generate  invariants  of  the  form 

r  —  Vi  =r*  Ci , 

where  Ci  is  a  predicate  over  the  variables  in  £  on  which  r 
depends.  Invariant  generation  from  SCR  tables  is  based  on 
the  following  idea:  In  an  SCR  specification,  r  =  Vi  =>■  Ci  is 
an  invariant  if  I  )  C,  is  always  true  when  r’s  value  changes 
to  Vi,  and  2)  an  event  falsifying  Ci  unconditionally  causes  r 
to  have  a  value  other  than  Vi.  Since  stronger  invariants  may 
be  computed  with  knowledge  of  previously  computed  in¬ 
variants,  the  full  algorithms  repeat  the  computations  of  the 
invariants  until  a  fixpoint  is  reached.  The  current  implemen¬ 
tation  of  the  SCR  invariant  generator  applies  our  algorithms 
to  both  mode  transition  tables  and  event  tables.  State  in¬ 
variants  constructed  from  a  mode  transition  table  are  called 
mode  invariants. 

We  have  also  developed  two  prototype  code  synthesiz¬ 
ers  that  construct  C  source  code  from  an  SCR  requirements 
specification  [21],  The  two  synthesizers,  each  using  a  dif¬ 
ferent  code  generation  strategy,  are  based  on  Paige’s  APTS 
program  transformation  system  [30].  The  first  strategy  uses 
rewrite  rules  to  transform  the  parse  tree  of  an  SCR  specifi¬ 
cation  into  a  parse  tree  for  the  corresponding  C  code.  The 
second  strategy  associates  a  relation  with  each  node  of  the 
specification  parse  tree.  Each  member  of  this  relation  acts 
as  an  attribute,  holding  the  C  code  corresponding  to  the  tree 
at  the  associated  node;  the  root  of  the  tree  has  the  entire  C 
program  as  its  member  of  the  relation.  The  generated  code 
is  efficient  but  has  not  been  optimized. 


Mode  Pressure 

Events 

TooLow, 

@T(Block  =  On) 

@T(Pressure  =  High)  OR 

Permitted 

WHEN  Reset  =  Of  f 

@T(Reset  =  On) 

High 

False 

@F(Pressure  =  High) 

Overridden 

True 

False 

Table  3.  Event  Table  for  Overridden. 


Overridder/ 


true  if  @T(Block=on)  WHEN  Reset=of  f 

AND  Pressure  in  {TooLow,  Permitted} 
false  if  @T(Pressure=High)  OR  @T(Reset=on)  WHEN 

Pressure  in {TooLow,  Permitted} 

OR  @F(Pressure=  High)  WHEN  Pressure=High 
Overridden  otherwise 


Figure  2.  Functional  Definition  of  Overridden  Event  Table. 


3.  Simplifying  SCR  Tables  Using  Invariants 

This  section  presents  two  simplification  rules  that  make 
use  of  invariants:  (1)  a  rule  to  remove  unreachable  parts  of 
the  specification  and  (2)  another  rule  to  remove  redundant 
parts  of  the  specification.  Since  invariants  are  properties 
that  hold  in  any  reachable  state,  invariants  may  be  used  to 
simplify  the  expression  of  the  next  state  function,  the  func¬ 
tion  from  which  code  is  ultimately  generated.  Note  that, 
to  simplify  an  expression  E,  it  is  not  sufficient  to  simply 
conjoin  the  invariants  with  E  and  apply  some  simplification 
procedure,  because  this  might  entail  the  simplification  of 
both  E  and  the  invariants,  when  all  we  want  to  simplify  is 
E  itself.  Thus,  some  form  of  expression  simplification  that 
uses  the  invariants  as  context  is  desired. 


in  Table  3  the  mode  context  for  the  cell  “@F(Pressure 
=  High)”  obtained  from  the  associated  mode  class  Pres¬ 
sure  is  “Pressure  =  High,”  while  the  mode  context  for 
the  cell  in  row  2  in  Table  4  on  page  7  is  “CruiseMode  = 
Inactive.” 

B.  CONSTRAINT  ON  THE  OLD  VALUE  (Rule 
Remove-Unreachable  Only):  For  an  event  table,  a  con¬ 
straint  on  the  old  value  of  the  variable  being  defined  can  also 
be  used  as  part  of  the  context  of  a  cell.  Event  tables  have 
a  default  “no  change”  condition,  meaning  that  for  a  given 
cell,  we  only  need  to  consider  the  value  of  the  variable  if 
the  actual  value  of  the  variable  changes.  This  is  supported 
by  the  following  property  related  to  the  formal  definition  of 
tables  as  given  in  [13],  of  which  Figure  2  is  an  example. 


3.1.  Contexts 

For  each  cell  to  be  simplified,  several  different  forms  of 
information  may  be  assumed  as  context:  the  current  value 
of  the  associated  mode  class,  a  constraint  on  the  old  value 
of  the  variable  being  defined  in  the  table,  and  the  set  of  in¬ 
variants.  However,  for  a  technical  reason  (as  explained  in 
the  appendix)  the  contextual  information  involving  the  old 
value  of  the  variable  may  only  be  used  as  context  for  the 
Rule  Remove-Unreachable. 


Property  1  For  a  variable  r  having  the  set  of  possible  val¬ 
ues  {i>i, . . . ,  vn},  the  function  definition 


[  vi  if  Pi 


r 


/ 


< 


Vn  ifPn 
r  otherwise 


is  equivalent  to  the  definition 


A.  THE  MODE  CLASS  (Both  Rules):  Usually  an 
event  table  in  SCR  has  an  associated  mode  class  M ;  that 
is,  the  value  of  the  variable  defined  by  the  table  is  described 
as  a  function  of  that  mode  class  and  an  event.  Except  for 
mode-less  event  tables,  the  mode  in  the  old  state  can  be  used 
as  part  of  a  cell's  context.  For  mode  transition  tables,  the 
value  of  the  mode  in  the  old  state  can  be  used  as  context  for 
the  cell  in  the  corresponding  event  column.  For  example. 


(  Vi  if  Pi  A  r^vi 


r 


/ 


< 


Vn  if  Pn  V  f1  Vn 

r  otherwise 


if  the  set  {Pi,  P2, ...,  Pn}  satisfies  Disjointness, 
j  =>  ~^{Pi  A  Pj)  for  all  1  <i,j<n. 


i  t 


This  property  also  holds  when  only  conjoining  r  -f  v,  for 
some  subset  of  the  Pi  rather  than  all  of  the  Pi.  Thus  for 
each  cell  in  the  definition  of  the  new  value  r'  defined  by 
an  event  table  we  have  the  context  r  ^  v  where  v  is  the 
value  below  the  double  line  at  the  bottom  of  the  column 
containing  that  designated  cell.  For  example,  in  Table  3  this 
gives  the  context  for  the  “@F(Pressure  =  High)”  cell  as 
“Overridden  7^  false.” 

C.  THE  INVARIANTS  (Both  Rules):  Though  any  state 
invariant  of  E  can  be  used  as  context,  this  paper  only  con¬ 
siders  mode  invariants,  i.e.,  state  invariants  of  the  form 
M  =  nii  =>  Qi,  where  M  is  a  mode  class  name  and  Qi 
is  a  predicate  defined  on  state  variables  of  E. 

3.2.  Simplification  Rules 

For  an  intuitive  presentation  of  our  simplification  tech¬ 
niques  using  invariants,  we  express  the  simplifications  in 
terms  of  transformations  of  the  cells  of  an  SCR  table.  A 
tool  implementing  these  simplifications  would  define  these 
transformations  directly  in  terms  of  the  conditional  expres¬ 
sions  defining  the  semantics  of  each  table,  but  the  results 
would  be  equivalent.  For  example,  consider  the  event  table 
in  Table  3.  This  table,  which  is  adapted  from  the  SCR  spec¬ 
ification  of  a  safety  injection  system  [13],  describes  how 
the  value  of  the  variable  Overridden  is  updated.  The  se¬ 
mantics  of  Table  3  is  given  as  the  conditional  expression  of 
Figure  2. 

Our  simplifications  apply  to  cells  containing  the  event 
expressions  occurring  in  event  tables  (e.g.  the  cells  above 
the  double  line  with  header  “Events”  in  Table  3)  and  mode 
transition  tables  (the  cells  with  the  header  “Event”  in  Ta¬ 
ble  4).  As  a  special  case  a  cell  may  contain  false,  meaning 
that  the  case  is  impossible.  Our  simplifications  are  contex¬ 
tual  in  the  sense  that  we  shall  simplify  cells  in  the  context  of 
the  given  invariants  plus  additional  facts  as  described  above. 
In  this  paper,  we  present  only  two  rules,  both  defined  over  a 
logical  expression  K,  the  context  of  a  cell,  and  E,  the  event 
expression  contained  in  that  cell. 

Context  for  Remove-Redundancy:  K  =  ( M  = 

in)  A  I,  where  (a)  m  is  the  old  value  of  the  mode 
class  M  associated  with  the  cell,  (b)  I  is  some 
state  invariant  (in  the  old  state). 

Rule  Remove-Redundancy:  If  E  is  an  expres¬ 
sion  containing  a  subexpression  Q  for  a  cell  as¬ 
sociated  with  mode  value  m,  and  K  =>  Q  is  a 
tautology,  then  E  may  be  simplified  by  replacing 
each  occurrence  of  Q  within  E  with  true. 

Intuitively,  this  rule  says  that  if  cell  E  is  being  evalu¬ 
ated  in  a  context  where  both  K  and  Q  are  true,  then  ef¬ 


fectively  the  value  of  E  is  unchanged  by  treating  each  oc¬ 
currence  of  Q  as  true.  If  applying  this  rule  simplifies  E, 
one  would  naturally  further  simplify  E  using  standard  sim¬ 
plification  algorithms.  In  this  paper,  we  shall  only  apply 
Remove -Redundancy  to  mode  transition  tables. 

Context  for  Remove-Unreachable:  K  =  (. M  = 

m)  A  I  A  (r  7^  v),  where  (a)  in  is  the  old  value 
of  the  mode  class  M  associated  with  the  cell  con¬ 
taining  E,  (b)  I  is  some  state  invariant  (in  the  old 
state),  and  (c)  v  is  the  new  value  of  r  associated 
with  the  cell. 

Rule  Remove-Unreachable:  If  K  A  E  =>■  false 

is  a  tautology,  then  E  may  be  replaced  by  false. 

Obviously,  if  the  context  is  false,  then  the  transition  as¬ 
sociated  with  this  cell  will  never  occur.  Replacing  the  cell 
entry  with  false  results  in  a  clearer  and  more  concise  spec¬ 
ification. 

Next,  we  illustrate  several  simplifications  using  Rule 
Remove-Redundancy.  Table  4  shows  the  mode  transition 
table  for  a  Cruise  Control  system  [11].  Applying  our  previ¬ 
ously  developed  invariant  generation  algorithms,  produces 
the  following  two  invariants  for  the  cruise  control  specifica¬ 
tion:  (1)  CruiseMode  =  Inactive  =>  IgnOn  and  (2) 
CruiseMode  =  Override  =>  IgnOnAEngRunning. 
Consider  Row  3  of  Table  4  and  let  E  be  the  event  expres¬ 
sion  from  this  row.  Let  I  be  the  invariant  (1)  and  take  the 
context  K  to  be  /  together  with  the  mode  context  for  this 
row,  CruiseMode  =  Inactive.  Together  these  two 
parts  of  the  context  imply  IgnOn.  Applying  Rule  Remove- 
Redundancy  with  Q  =  IgnOn  eliminates  “And  IgnOn” 
from  the  end  of  the  event  expression  in  the  cell  (marked  in 
italics).  Code  generated  from  the  simplified  table  will  be 
smaller  and  faster  than  code  generated  from  the  original  ta¬ 
ble.  Similarly,  we  can  simplify  line  9  of  the  mode  transition 
table  using  invariants  (1)  and  (2)  to  remove  the  expression 
“And  IgnOn  And  EngRunning”  (shown  in  italics). 

Finally,  we  illustrate  how  applying  Rule  Remove- 
Unreachable  will  lead  to  elimination  of  a  row  of  Table  3. 
This  corresponds  to  elimination  of  a  part  of  the  specifica¬ 
tion  that  would  produce  dead  code  during  synthesis.  Let 
E  be  the  cell  containing  @F(Pressure  =  High)  in  the 
event  table  given  in  Table  3  and  let /  be  Pressure  = 
High  =>  Overridden  =  false,  one  of  the  gener¬ 
ated  state  invariants  for  this  system.  Let  the  context  K 
be  the  invariant  /  together  with  the  mode  class  informa¬ 
tion,  Pressure=High,  and  the  old  state  value  informa¬ 
tion,  Overridden  7^  false.  The  three  constraints  of  the 
context  K  taken  together  simplify  to  false',  and  thus  by  the 
Rule  Remove-Unreachable  the  cell  itself  can  be  replaced  by 
false.  Because  all  the  cells  in  the  second  row  of  the  table 
now  are  false,  the  entire  row  of  the  table  can  be  eliminated. 


Old  Mode 

Event 

New  Mode 

1  Off 

@T(IgnOn) 

Inactive 

2  Inactive 

@F(IgnOn) 

Off 

3  Inactive 

@T(Lever  =  const)  WHEN  EngRunning 

AND  NOT  Brake  AND  IgnOn 

Cruise 

4  Cruise 

@F(IgnOn) 

Off 

5  Cruise 

@F(EngRunning) 

Inactive 

6  Cruise 

@T(Brake)  OR  @T(Lever  =  off) 

Override 

7  Override 

@F(IgnOn) 

Off 

8  Override 

@F(EngRunning) 

Inactive 

9  Override 

@T(Lever  =  resume)  OR  @T(Lever  =  const)  WHEN 
NOT  Brake  AND  IgnOn  AND  EngRunning 

Cruise 

Table  4.  Mode  Transition  Table  for  Mode  Class  Variable  CruiseMode. 


The  more  compact  table  is  shown  in  Table  5.  The  new  table 
will  produce  less  code  during  synthesis  because  it  omits  the 
part  of  the  table  that  would  lead  to  the  construction  of  dead 
code. 

There  is  one  special  case  of  Remove-Unreachable  that 
bears  mention.  If  there  is  an  invariant  of  the  form  M  =  m  => 
false,  any  row  of  a  table  having  M  =  m  as  the  mode  class 
context  can  be  eliminated  from  the  table.  This  one-step  opti¬ 
mization  is  equivalent  to  a  series  of  applications  of  Remove- 
Unreachable  (one  for  each  cell  in  the  row),  resulting  in  a 
row  of  cells  having  the  value  false,  followed  by  the  elimi¬ 
nation  of  the  row. 

4.  Related  Work 

The  language  LUSTRE  [8],  developed  at  VERIMAG,  is 
conceptually  similar  to  the  SCR  language:  it  provides  a  de¬ 
terministic  language,  in  which  all  non-input  variables  are 
simultaneously  updated  in  response  to  some  change  in  the 
input  environment.  Efficient  code  generation  is  an  integral 
part  of  the  LUSTRE  toolset,  and  is  based  on  the  use  of  a 
“control  automaton”  that  remembers  a  limited  part  of  the 
old  state  of  the  system.  The  VERIMAG  group  has  also  ex¬ 
tended  LUSTRE  into  the  hardware  area  by  adding  syntac¬ 
tic  sugar  for  array  structures  and  circuit  layout  information, 
which  the  Pollux  tool  uses  to  automatically  configure  the 
hardware  gates  in  Programmable  Active  Memory  [34], 

Early  work  on  logical  simplification  in  the  1950’s 
and  1960’s  addressed  Boolean  minimization  with  respect 
to  some  measure  (such  as  fewest  number  of  literals  in 
sum-of-products  form)  resulting  in  the  well-known  Quine- 
McCluskey  method  [33,  25].  Later  developments  extended 
simplification  over  first-order  theories  with  interpreted  sym¬ 
bols:  Loveland  and  Shostak  [24]  extended  Quine’s  method 
of  prime  implicants,  while  Zhang  [36]  gives  a  general 
framework  for  simplification  via  contextual  rewriting,  i.e., 
rewriting  formulae  in  the  context  of  additional  information. 


This  latter  work  has  been  extended  to  consider  use  of  deci¬ 
sion  procedures  in  manipulating  the  context  during  rewrit¬ 
ing  [3].  The  most  sophisticated  of  these  techniques  have 
resulted  in  implementations  of  powerful  theorem  provers, 
e.g.,  SIMPLIFY,  which  is  based  on  the  work  of  Nelson  [29]. 
The  two  rules  we  have  given  are  special  cases  of  contex¬ 
tual  rewriting  as  originally  defined  by  Remy  [35],  who  first 
coined  the  terminology  “contextual  rewriting.” 

Complementing  the  early  work  on  logic  simplification  in 
the  1950’s  and  1960’s  was  the  development  of  techniques 
for  machine  simplification,  e.g.,  the  minimization  of  the 
number  of  states  of  incompletely  specified  finite  state  ma¬ 
chines  [32].  The  monograph  by  Kam  et  al.  gives  a  modern 
perspective  on  this  subject  [18], 

Invariants  have  been  used  for  optimization  during  code 
generation  for  many  years,  but  for  the  most  part  such  in¬ 
variants  are  related  to  implementation  details  rather  than  re¬ 
quirements  level  invariants  of  reactive,  embedded  systems 
that  we  generate  from  SCR  specifications.  For  example, 
“loop  invariants”  about  the  relative  values  of  variables  in 
a  loop  are  used  during  the  classic  strength-reduction  com¬ 
piler  optimization  technique  [1]  and  the  finite  differencing 
program  transformation  technique  [30].  More  recent  work 
on  strengthening  such  invariants  has  led  to  additional  op¬ 
timization  as  well  as  providing  a  more  general  approach 
called  incrementalization  [23].  Another  application  of  in¬ 
variants  during  code  generation,  but  at  a  higher  level  akin 
to  requirements,  is  the  technique  of  run-time  code  genera¬ 
tion  [22,  19].  In  this  method,  specialized  code  is  generated 
at  run-time,  given  invariants  based  upon  the  known  input 
values  for  a  specialized  (often  one-time)  use  of  a  program. 

In  our  simplification  of  the  cells  of  a  table,  we  use  the  old 
state  value  of  the  variable  as  means  of  restricting  the  calcu¬ 
lation  of  the  variable’s  new  value  to  only  the  cases  where 
there  is  to  be  a  change  from  the  old  value  of  the  variable. 
This  check  of  the  old  value  of  the  variable  could  also  be 
generated  as  part  of  the  synthesized  code.  If  the  check  were 


Mode 

Events 

TooLow, 

Permitted 

@T(Block  =  On) 

WHEN  Reset  =  Of  f 

@T(Pressure  =  High)  OR 
@T(Reset  =  On) 

Overridden 

True 

False 

Table  5.  Simplified  Event  Table  for  Overridden. 


Overridden/ 


true 

false 

Overridden 


if  @T(Block=on)  WHEN  Reset=of  f 
AND  Pressure  in  {TooLow,  Permitted} 
if  @T(Pressure=High)  OR  @T(Reset=on)  WHEN 
Pressure  in {TooLow,  Permitted} 
otherwise 


Figure  3.  Functional  Definition  of  Simplified  Overridden  Event  Table. 


generated  such  that  it  was  a  preliminary  check  before  the 
rest  of  the  calculations  were  performed,  it  would  optimize 
the  code  by  preventing  unnecessary  calculations.  This  sort 
of  incremental  update  to  the  variable  (i.e.,  basing  its  new 
value  upon  its  old  value)  as  well  as  the  LUSTRE  control 
automaton  approach  to  compilation  are  similar  to  finite  dif¬ 
ferencing  [30]. 

5.  Conclusions  and  Future  Work 

Though  at  a  preliminary  stage,  the  work  reported  in  this 
paper  shows  that  some  benefit  can  be  derived  from  using  in¬ 
variants  to  simplify  SCR  specifications.  In  future  work,  we 
plan  to  implement  a  tool  that  applies  more  general  invari¬ 
ants  (to  include  transition  invariants)  to  simplify  SCR  ta¬ 
bles  using  algorithms  that  support  contextual  simplification 
in  the  more  general  setting  of  interpreted  first-order  theo¬ 
ries,  (e.g.,  arithmetic  expressions,  enumeration  expressions, 
etc.).  While  the  simple  idea  of  a  cell  and  its  context  pro¬ 
vide  an  intuitive  framework  for  explaining  the  optimization 
of  SCR  specifications,  the  implementation  will  perform  the 
optimizations  directly  on  the  underlying  functional  defini¬ 
tions.  The  output  of  this  tool  will  then  be  used  as  input  for 
our  previously  developed  code  synthesizers,  allowing  us  to 
produce  code  that  has  been  optimized.  We  plan  to  perform 
experiments  to  determine  the  amount  of  improvement  the 
optimizations  provide  for  typical  SCR  specifications.  We 
also  plan  to  implement  the  finite  differencing  optimization 
described  in  Section  4. 
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A.  Soundness 

We  have  formally  proved  that  both  rules  are  sound,  each 
with  its  own  particular  definition  of  context.  Although  these 
rules  appear  to  be  quite  simple,  careful  attention  to  the  al¬ 
lowable  context  is  required.  It  would  seem  intuitive  that  the 
constraint  on  the  old  value  of  the  variable  v  could  be  used 
as  context  with  Rule  Remove -Redundancy  since  a  transfor¬ 
mation  via  Property  1  preserves  the  function.  But  this  is 
unsound:  it  is  easy  to  find  an  SCR  table  for  which  applica¬ 
tion  of  Rule  Remove-Redundancy  with  the  constraint  r/t) 
as  part  of  the  context  introduces  nondeterminism. 

We  now  present  the  proof  of  the  soundness  of  Rule 
Remove-Unreachable  for  an  event  table.  The  proof  is  for 
the  more  general  case  of  application  of  the  rule  to  all  cells 
simultaneously.  To  avoid  clutter  we  suppress  explicit  men¬ 
tion  of  the  state.  We  consider  the  semantics  of  an  event  table 
defining  the  new  value  of  a  state  variable  r  as  a  conditional 
expression: 


Fr  =  < 


V\  if  G\ 

vn  if  Gn 


r 


otherwise 


if  G\  A  (r  ±  ui) 


de  f 

where  the  set  of  guards  Gi  =  ( M  =  mi)  A  Ei,  i  = 
1, . . .  ,n  are  mutually  disjoint;  this  ensures  that  this  con¬ 
ditional  form  represents  a  function. 

For  every  i,  the  Remove-Unreachable  context  for  E,  is 

I<i  =  (M  =  mi)  Af,A(r  /  vi) 

where  It  is  some  state  invariant,  which  may  be  chosen  dif¬ 
ferently  for  each  i.  Recall: 

Rule  Remove-Unreachable:  If  [Kl  A  Ei)  => 

false  is  a  tautology,  then  replace  Ei  with  false. 

After  applying  this  rule  for  every  i,  we  have  a  new  definition 
Ff ,  with  each  Gi  in  the  definition  of  Fr  replaced  by  G*, 
where 

G*  =  (. M  =  mi)  A  E*,  (1) 

in  which 

false  if  ( Ki  A  Ei)  =>  false 

•  (2) 
Ei  otherwise. 

Note  that  (1)  and  (2)  together  imply  that  G*  =>  Gi. 

For  F*  to  define  a  well-formed  table  function,  the  G* 
must  be  mutually  disjoint.  But  this  fact  is  easily  established 
since  the  only  modification  to  Fr  is  to  (possibly)  replace 
some  of  the  E,  by  false. 


vi 

< 

vn  if  Gn  A  (r  /  vn) 

r  otherwise. 

To  show  that  this  expression  also  evaluates  to  r,  it  suf¬ 
fices  to  show 

Vi  :  ->(Gi  A(r  /  vt))  (6) 

holds.  But  if  (6)  is  false  then  there  is  some  i  such  that 
Gi  A  (r  /  vi)  holds.  In  this  case,  r  ^  Vi,  and  since  Gi 
holds,  we  also  have  M  =  mi  and  E, .  Further,  Ii  holds 
because  state  invariants  hold  in  any  reachable  state.  There¬ 
fore,  we  know  that  Ki  =  ( M  =  mi)  A  Ii  A  (r  ^  vi) 
holds.  Thus,  Ki  A  Et  holds,  which  means  that  Ki  A  Ei  => 
false  does  not  hold.  From  this,  we  know  E*  =  Ei 
(by  (2)),  and  hence,  G*  =  Gi  (by  (1)).  Because  Gi 
holds,  G*  also  holds.  But  this  contradicts  the  assumption 
Vi  :  A G*.  Therefore,  we  have  established  (6). 

CASE  [3 i  :  G*]:  Choose  i  such  that  G*  holds.  Then 
the  case  expression  in  (4)  evaluates  to  v, .  Since  G*  =>  Gi, 
Gi  also  holds.  But  this  means  that  the  value  of  the  case 
expression  in  (3)  also  evaluates  to  U;.  Hence,  the  values  of 
the  two  case  expressions  are  equal.  ■ 


Theorem  1  Semantically,  with  respect  to  the  reachable 
states  of  the  system,  Fr  =  Ff. 


Proof:  In  our  proof,  we  may  assume  that  all  evaluation 
takes  place  in  a  reachable  state. 

The  definition  of  Ff  expands  to 

f  vt  if  GI 


r 


r 


< 


Vn  if  G* 

r  otherwise 


(3) 


and  the  definition  of  Fr  expands  to 


V\  if  Gi 

Vn  if  Gn 

r  otherwise. 


(4) 


We  must  show  that  the  values  of  these  two  case  expressions 
are  equal.  We  need  only  consider  two  cases. 


CASE  [Vi  :  _|G*]:  In  this  case,  the  conditional  expres¬ 
sion  in  (3)  evaluates  to  r.  Using  Property  1  on  page  5  we 
can  rewrite  the  conditional  expression  in  (4)  to: 


